[調査報告] Amazon Athena 従来のS3ファイルレイアウトとIcebergテーブルフォーマットのデータ容量比較

AWS事業本部コンサルティング部の石川です。大規模データ管理では、S3上のデータ容量のサイズを事前に把握し、コスト試算をすることが欠かせません。今日は、Amazon Athenaのデータ管理に使用される2つの主要なフォーマット、従来のS3ファイルレイアウトと Apache Icebergのテーブルフォーマットの特長やデータ容量比較について解説します。

データレイクフォーマットの概要

データレイクフォーマットは、従来のS3ファイルレイアウトとApache Icebergのテーブルフォーマットの2種類があります。

補足: Amazon Athenaは、将来的に、Apache Icebergの他にApache HudiやLinux Foundation Delta Lake などのテーブルフォーマットもサポートされるかもしれません。

従来のS3ファイルレイアウト

「従来の S3 ファイルレイアウト」という呼び方は、Hive スタイル、非 Hive スタイル、および非パーティションテーブル包括的に表現です。

1. Hive スタイルパーティション

   • key=valueのペアを使用したディレクトリ構造（例：year=2021/month=01/day=26/）
   • ALTER TABLE ADD PARTITION コマンドで手動でパーティションを追加
   • MSCK REPAIR TABLE コマンドでパーティションを一括追加も可能

2. 非 Hive スタイルパーティション

   • 通常の階層的なディレクトリ構造（例：2021/01/26/）
   • ALTER TABLE ADD PARTITION コマンドで手動でパーティションを追加

3. 非パーティションテーブル

   • パーティションを使用せず、すべてのデータが同じディレクトリに格納される

これらの3つのタイプは、いずれも Amazon S3 上の従来のファイル構造を使用しており、AWS Glue Data Catalog を通じて Athena からアクセスできます。

Apache Icebergのテーブルフォーマット

Apache Icebergは、大規模なデータレイク向けに設計されたオープンソースのテーブルフォーマットで、従来のS3ファイルレイアウトとは異なる新しいテーブルフォーマットです。Iceberg は、スナップショット管理とメタデータの高度な管理を通じて、ACID 特性を持つワークフローを可能にする、より高度なテーブル管理機能を提供します。

したがって、従来の S3 ファイルレイアウトと、Iceberg のような新しいテーブルフォーマットと区別されます。

サンプルデータ

従来のS3ファイルレイアウト（TSV）のテーブルは、以下のように定義されています。

• 300万レコード
• 非パーティションテーブルです。
• TSV形式のGZIP圧縮ファイル、100MB（非圧縮273MB）

CREATE EXTERNAL TABLE `customer`(
  `c_custkey` int,
  `c_name` varchar(25),
  `c_address` varchar(25),
  `c_city` varchar(10),
  `c_nation` varchar(15),
  `c_region` varchar(12),
  `c_phone` varchar(15),
  `c_mktsegment` varchar(10))
ROW FORMAT DELIMITED
  FIELDS TERMINATED BY '\t'
STORED AS INPUTFORMAT
  'org.apache.hadoop.mapred.TextInputFormat'
OUTPUTFORMAT
  'org.apache.hadoop.hive.ql.io.HiveIgnoreKeyTextOutputFormat'
LOCATION
  's3://<mybucket>/ssbgz_tsv/customer'
TBLPROPERTIES (
  'CrawlerSchemaDeserializerVersion'='1.0',
  'CrawlerSchemaSerializerVersion'='1.0',
  'UPDATED_BY_CRAWLER'='customer',
  'areColumnsQuoted'='false',
  'classification'='csv',
  'columnsOrdered'='true',
  'compressionType'='gzip',
  'delimiter'='\t',
  'transient_lastDdlTime'='1690576375',
  'typeOfData'='file')

以降では、TSV、JSON、Icebergの3つのテーブルを作成して、それぞれのディスク容量を比較します。

TSVからJSONへのフォーマット変換

従来のS3ファイルレイアウト（TSV）のテーブルを、従来のS3ファイルレイアウト（JSON）のテーブルへINSERT INTO SELECTでデータをコピーすることによって、データを変換します。

• 300万レコード
• JSON形式のGZIP圧縮ファイル、105MB（非圧縮574MB）

TSVからIcebergへのフォーマット変換

従来のS3ファイルレイアウト（TSV）のテーブルを、IcebergテーブルフォーマットのテーブルへINSERT INTO SELECTでデータをコピーすることによって、データを変換します。

• 300万レコード
• Icebergフォーマットファイル群の合計、180MB

補足: Parquet-Toolsによる調査

Icebergでは、直近のデータを除き、データはParquetファイルで保存します。データファイルは、パーティション毎にファイルが分かれるため、その中の1つのファイルをParquet-toolsを用いてメタデータを確認しました。

parquet-toolsのmetaサブコマンド出力では、カラムナストレージ ファイル形式、特に Parquet ファイルの詳細なメタデータが提供されます。このメタデータは、行グループ、データ型、エンコードスキーム、データ分布、サイズ特性、およびファイル内に格納されているデータセットの潜在的な圧縮に関する情報を提供します。

• 合計 (GZIP圧縮): 17.857 MB
  • 圧縮されたときのデータの合計サイズであり、使用された圧縮アルゴリズムの効果を示します。
• 合計 (非圧縮): 37.984 MB
  • 圧縮なしのデータのサイズであり、圧縮の効果を示すコントラストを提供します。
• カラム
  • Type: 列のデータ型 (例: 32 ビット整数の場合は INT32、可変長文字列またはバイナリ データの場合は BINARY)

% parquet meta ./20240831_044046_00007_pfsst-e5645702-0ed8-472f-ab44-a7ebb65c0920.parquet
\
File path:  ./Downloads/20240831_044046_00007_pfsst-e5645702-0ed8-472f-ab44-a7ebb65c0920.parquet
Created by: parquet-mr-trino version 0.215-18767-g79a5b50 (build n/a)
Properties: (none)
Schema:
message table {
  optional int32 c_custkey = 1;
  optional binary c_name (STRING) = 2;
  optional binary c_address (STRING) = 3;
  optional binary c_city (STRING) = 4;
  optional binary c_nation (STRING) = 5;
  optional binary c_region (STRING) = 6;
  optional binary c_phone (STRING) = 7;
  optional binary c_mktsegment (STRING) = 8;
}

Row group 0:  count: 600018  31.21 B records  start: 4  total(compressed): 17.857 MB total(uncompressed):37.984 MB
--------------------------------------------------------------------------------
              type      encodings count     avg size   nulls   min / max
c_custkey     INT32     Z   _     600018    3.28 B     0       "3" / "2999991"
c_name        BINARY    Z   _     600018    4.60 B     0       "Customer#000000003" / "Customer#002999991"
c_address     BINARY    Z   _     600018    13.36 B    0       "   821GWWo" / "zzzou4P"
c_city        BINARY    Z _ R     600018    1.00 B     0       "ALGERIA  0" / "VIETNAM  9"
c_nation      BINARY    Z _ R     600018    0.63 B     0       "ALGERIA" / "VIETNAM"
c_region      BINARY    Z _ R     600018    0.34 B     0       "AFRICA" / "MIDDLE EAST"
c_phone       BINARY    Z   _     600018    7.66 B     0       "10-100-138-8513" / "34-999-923-9619"
c_mktsegment  BINARY    Z _ R     600018    0.34 B     0       "AUTOMOBILE" / "MACHINERY"

比較結果

ファイルサイズを比較すると一見Icebergが大きく見えますが、IcebergはカラムなファイルフォーマットParquetでデータが保存されているため、レコードブロックの読み飛ばしや必要なカラムのみをスキャンできるため、分析用途のワークロードに適したフォーマットで保存されます。

よって、GZIP圧縮済みのTSVファイルやJSONファイルと比較して、Icebergフォーマットは2倍程度が目安になります。一見するとIcebergのファイルサイズが大きく見えますが、重要な点はファイルサイズだけではありません。

補足: Icebergテーブルフォーマットの圧縮形式

Athena エンジンバージョン 3 における ParquetのIceberg のデフォルトの圧縮形式は ZSTD です。

https://docs.aws.amazon.com/ja_jp/athena/latest/ug/compression-support-iceberg.html

https://docs.aws.amazon.com/ja_jp/athena/latest/ug/compression-support-zstd-levels.html

G: GはRLE（ランレングスエンコーディング）およびビットパッキングエンコーディングを表し、定義レベル、繰り返しレベル、辞書インデックスのエンコーディングに使用されます。これは、これらの部分を効率的にエンコードするためにParquetが利用するハイブリッドエンコーディングです。ただし、ドキュメントやバージョンによっては、"G "が一部のエンコーディングの側面を特に指している場合もありますが、コミュニティやドキュメントでは上記の解釈が一般的です。

Z: Zはデルタエンコーディングの略で、連続する値の差を符号化するエンコーディングの一種であり、漸進的に変化するデータに対して非常に効率的です。デルタエンコーディングは、値が漸増または漸減する数値列に特に効果的です。

Icebergテーブルフォーマットの特長

• カラムナーストレージ

  • Icebergは内部でParquetフォーマットを使用し、カラムナーストレージを実現しています。これにより、必要なカラムのみをスキャンでき、分析クエリの効率が大幅に向上します。

• 高度な圧縮

  • IcebergはデフォルトでZSTD圧縮を使用しており、効率的なデータ圧縮を実現しています。

• クエリ最適化

  • レコードブロックの読み飛ばしや、必要なカラムのみのスキャンが可能で、分析ワークロードに最適化されています。

• スキーマ進化

  • Icebergはスキーマの変更を柔軟に扱えるため、長期的なデータ管理に適しています。

最後に

Icebergフォーマットは、単純なファイルサイズ比較では従来のS3ファイルレイアウト（TSV）より大きく見えますが、その高度な機能と最適化により、大規模データ分析において優れたパフォーマンスを発揮します。GZIP圧縮済みのTSVファイルやJSONファイルと比較して、Icebergフォーマットは約2倍のサイズになりますが、その追加サイズは高度な機能と引き換えに十分な価値があると言えるでしょう。

テーブルフォーマットは、単純なストレージコストだけでなく、クエリ性能、管理の容易さ、スケーラビリティなども考慮に入れる必要があります。その点で、Icebergは、これらの要素をバランス良く提供する現代的なデータレイクフォーマットとして、多くの企業で採用が進められています。